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1. INTRODUCTION 


The objective of the Cost Reduction Alternativee Study (Study II) 
was to define and compare alternative approaches to Payload Operations 
Planning and Control and Flight Crew Training for Spacelab payloads with 
the goal of: 

• Lowering FY 77 and FY 78 costs for new starts 

s Lowering costs to achieve Spacelab operational capability 

• Minimizing the cost per Spacelab flight. 

These alternatives attempt to minimize duplication of hardware, software 
and personnel and the investment in supporting facility and equipment. 

The alternatives were derived from the basic NASA guidelines for the 
study. Of particular importance to the TRW effort is the possible reduc- 
tion of equipment, software and manpower resources such as computational 
systems, trainers and simulators, 

1. 1 SCOPE OF STUDY 

The Payload Operations Planning and Control task included the 
Spacelab payload preflight planning, realtime replanning, and experiment 
data preprocessing functions of STS operations. The scope of the Flight 
Crew Training task included the training of the experiment crew neces- 
sary to assure their adjustment to the space environment, their ability to 
live and work in the Orbiter and Spacelab and to operate Spacelab systems 
in support of the experiment operations. 

Each of the tasks within the Cost Reduction Alternative study was 
es'<ablished to define and compare logical alternative approaches to the 
functions being conside-red and to determine the sensitivity of the results 
and conclusions to significant variations in assumptions and constraints. 

The general approach was developed to accomplish the following: 

• Prevent the buildup of facilities and their support equipment 
and personnal in advance of traffic buildup. 

• Reduce the stress toward optimizing mission parameters such 
as flight crew timelines, use of Shuttle payload weight, and 
use of utility resources. 

• Accept lower confidence levels in reliability and checkout 
status of experiment hardware and software than on Skylab. 
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• Minimize or avoid mission dependent hardware and software 
changes between flights. 

To accomplish these objectives the following tasks were performed; 

Flight Operations Planning and Control 

1) Operations Concepts that Reduce Manpower 

2) Spacelab Payload Operations Center Requirements 

3) Experiment Data Preprocessing Alternatives 

Flight Crew Training 

Crew Training Task Analysis /Requirements Definition 

2) Training Equipment Evaluation 

3) Traj.iing Equipment Recommendations. 

Crew training studies were constrained to: 

• Experiment/Spacelab Interface Training 

• Habitability and Safety 

• Spacelab Systems Operations and Maintenance. 

The definition of the skills and training required to become proficient in 
the operation and maintenance of the experiment systems was not a part 
of this study. Assumptions regarding the duration, equipment or location 
of this training were made as necessary. 

To develop Alternative program scenarios, many of the study tasks 
require sensitivity analysis to payload type and flight rate. To assure 
continuity between all of the tasks several specific payloads and reference 
missions were selected. The traffic models and reference missions were 
developed by NASA Headquarters /Mission and Payload Integration and are 
representative of all Spacelab payloads. Five missions and three traffic 
models were defined as shown in Table 1-1. 
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Table 1-1, Spacelab Missions and Traffic Models for 
Cost Reduction Alternatives Study 


TRAFFIC 

MODEL 

calendar year I 

V!li 

61 

■7S 

63 

84 

■7S 

K 

87 

H 

9 ? 


91 

TM-I 

2 

B 

12 

17 

19 

21 

21 

24 

24 

24 

27 

29 

TM-2 

2 


7 

II 

El 

13 

D 

IS 

16 

16 

16 

16 

TM-3 

1 

2 

5 

7 

6 

9 

9 

10 

10 

10 

10 

10 

— 


$PACE»B MISSIONS 

• COMBINED ASTRONOMY 

• AMPS 

• LIFE SCIENCES 


1,2 RECOMMENDATIONS 

The Cost Reduction Alternatives* Study hj,s identified many alterna- 
tives which could be implemented in the Spacelab flight planning, real- 
time replanning and crew training plans and procedures. However, each 
payload represents a unique set of operational requirements. A sum- 
mary of these requirements is shown in Table 1-2. The table addresses 
the three major factors which define flight operations and training 
approaches: 

• Number of experiment systems 

• Complexity of the flight - interaction of flight sequence, 
vehicle and environment 

• Real time interaction of scientific results and flight plan. 


• multi-applications spacelab 

• ATL 


Table 1-2. Summary of Payload Ojjerational Requirements 


PAYLOAD 


NUMBER OF 
EXP. SYSTEMS 


1 COMPLEXITY 

REAL TIME interaction! 

CONSTRAINED 

ATTITUDE/ 

POINTING 

CONSTRAINED 

ORBITAL 

CONDITIONS 

CONSTRAINED 
ORDER OF 
PERFORMANCE 

RESULTS 

CHANGE 

PLAN 

RESULTS 

Change 

PROCEDURES 
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Each of these factors translates into the appropriate degree of crew 
training and crew involvement in experiment hardware development, and 
the complexity of the flight planning and real time ground support functions. 

Considering the previous discussion and the results of the CRAS 
studies the following recommendations are made: 


1) Flight operations and crew training plans must be flexible 

to allow for the significant difference in requirements between 
payloads. 

J-ead Payload Centers should be established for each Spacelab 
Cargo/ Payload to assure lowest :ost operations plans are 
adopted. 

3) Adopt decentralized flight planning at each lead center. Use 
institutional computer systems and limit planning iterations. 

4) Consider the combination of some aspects of flight planning 
and flight crew training. 

5) Plan for a modular Payload Operations Center (POC), based 
on the use of iTuni/micro processor3. 

6) Review the real need for high rate science data in the POC. 

7) Use upgraded hi-fi niockup and aft flight deck trainer/ 
simulator combined with SMS for training. 

8) Use engineering model and L« vel 11 and III integration 
facilities for "refresher" training. 

9) Plan for exjieriment CDMS emulation and workstation at each 
jiayload center for experiment / Spacelab subsystem interface 
training. 


I i-rU 




jli 1 .i 
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2. PAYLOAD OPERATIONS PLANNING AND CONTROL 


The general objective of this task was to search for approaches in 
operations planning and control which would minimize duplication of func* 
tions and hardware and reduce the cost per flight, and the investment in 
supporting facility and equipment hardware, software and personnel com- 
pared to the approach on which the Spacelab Baseline Program Plan was 
based. An evaluation of the baseline plan and the results of the data pre- 
processf.ng study were presented at mid-term. Following the mid-term 
briefing TRW was directed to perform the following specific tasks: 

1) Identify ways to reduce manpower for both real time re- 
planning (RTRP) and flight planning. 

2) Identify equipment, manpower and facilities required for the 
Payload C^erations Center (POC) by discipline, for each 
traffic model. 

2. 1 OPERATICNS CONCEPTS THAT REDUCE MANPOWER 

Lower costs for payload flight planning can be achieved by careful 
attention to fovir major factors. These four factors have been identified 
as important for reducing both non-recurring costs (e. g. , new computers 
and software) and recurring costs (e. g. , manpower per flight). In the 
material that follows, each factor is analyzed to determine its contribu- 
tion to cost- savings, and implementation methods for achieving these 
lower costs. The factors are: 

• Minimize Contingency /Malfunction Planning 

• Minimize Flight Planning Iterations 

« Maximize Use of Institutional Computer Systems 

• Maximize Common Use of Manpower. 

2. 1. I Minimize Contingency/Malfunction Planning 

The likely payload contingencies, their causes and remedial actions 
have been identified. It is important to note that all elements of the flight 
(Orbiter, Spacelab, experiment equipment, procedures and crew time- 
lines) will be developed to minimize the occurrence of malfunctions or 
contingencies; accordingly, it should be expected that malfunctions and 
contingencies will decrease as the STS and payload technology mature. 

Ine need for payload contingency planning will correspondingly decrease. 
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The Probable Actions shown in Table 2»1 all withing the cap* 
abilities of the POC and its supporting complement of Principal Investi- 
gators, experiment engineers and flight planners. The resources of the 
MCC will provide comparable support for workaround procedures for 
orbit insertion errors and Spaceiab subsystem malfunctions. From 
Skylab, experience shows that the flight crew is also capable of corrective 
actions for payload malfunctions and contingencies. 

Table 2-1. Most Contingencies are Solved 
by Change to ihe Timeline 


IXKKIMiNt 

CONT.NOINCY 

FACTO* 

FROIAIU CAUSf 

froiaile action 

GENERAL CHARACTERISTICS 

IXn«IMtNT 

IQUIFMfNI 

K*FO«MANCf 

EQUIFMCNT 

WEAKOOWN 

• FAULT isolation 

• workaround 

• LARGE NUMIER OF 

variations 

• largely unfredictaile 

• generally ONLY 
CAUSES LOSS OF EXPERI- 
MENT TIME 

• MOST LIKELY ACTION 
IS A CHANCE IN THE 
TIME LINE 

OKIITAl DfVIATlONS 

VARIATION IN 
LAUNCH time, 
INXITION 0«»IT, 
ETC. 

• REVISED TIME LINE 

NATURAL 

FHtNOMtNA 

occureke of 

FLARES, WEATHER, 
ETC. 

• REVISED TIMELINE 

HUMAN FACTOKS 

VARIATION OF 
CREW FCRFORMANCE 
IN ZERO-G 
ENVIRONMENT 

• REVISION OF 
EXPERIMENT PER- 
FORMANCE TIME 

• REVISED time line 

XlENTlF< 

DATA 

SCIENTIFIC 
PHENOMENA 
NOT AS EXPECTED 

• R. configuration 
OF EQUIPMENT 


2.1.2 Minimize Experiment Planning Iteration s 

Manpower and computers hours for payload flight planning are 
directly related to the number of times the flight plan is updated. It is 
recommended that a new plan, or an update of an existing plan, be ac- 
complished only at the following times: 

• When a flight plan is needed to support experiment equip- 
ment design specifications, or to assemble requirements 
for flight support from the STS, the launch site, communi- 
cations networks and other support agencies. 

• When hardware test data become available for integrating 
into detailed timelines, procedures, consumables and 
pointing analysis. As a subset, refinement of a detailed 
night plan may be necessary on the basis of simulation of 
experiment operations and training exercises. 
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The advantage of limited iterations is in a reduction of costs (man- 
power and computers) from the costs of continuous flight planning during 
the preflight periods. 

For Spacelab payloads, Figure 2-1 shows the minimum flight-plan 
iteration requirement together with their intended purpose. Flight plan 
"A" will be used to define total flight characteristics and constraints 
that must be considered in I'esign and test of the experiment equipment. 
Flight plan "B" is a detailed plan that will in lude experiment timelines, 
procedures, consumables and pointing, a;l of which should be compatible 
with the ac.ual flight hardware. Flight plan "C is an update that con- 
siders the irroact of simulations and integrated crew training; this flight 
plan becon. ; art of the Flight Data File. 



Figure 2-1. Experiment Flight I^lanning Iterations 


Manpower estimates were developed for the three iteration plan- 
ning scheme. Experienced flight planners are available both within 
NASA and in industry, and it is assumed such people would be assigned 
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to the flight planning function. The estimates for manpower were pro- 
vided by TRW people who supported the flight planning for Skylab, Apollo 
and ASTP, and who have reviewed the candidate Spacelab payloads. As 
a baseline, Multi-Applications payloads are considered to be of average 
complexity and are used for initial manpower estimates. Manpower 
estimates are shown in Figure 2-2 for the three iterations tc the flight 
plan and for a limited degree of flight plan maintenance. The values are 
consistent with the plan described in Figure 2-1, 
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nrriiniHii 

nm 
0 
□3 
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GE 

?1 MAN-MONThS 
PPEllMINA«y 


0 

□ 

Dm 

nm 

Qunniii 

DEHIB 

n.'t MM - »0:«MM-^| II MM j— — 

iusTAiNiNG Aciivirr ' atiAUED ’ final I 


81. S MM 



Figure 2-2. Nominal-Payload Man-Month Estimates 
For Flight Planning 

Flight plan maintenance is shown for a period that is typical of the 
manufacture and test of new experiment equipment. For reflights, this 
period would be shorter because this equipment would require only re- 
furbishment or minor modifications. Flight plan maintenance would be 
reduced accordingly. 

The manpower estimates are also consistent with use of the com- 
puter hours estimated elsewhere in this report. It is also assumed that 
the flight planners are collocated with the payloads' system engineers and 
have ready acces. to Principal Investigators, 
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Spacelab payload equipment ie expected to be used on successive 
flights with only slight modification between flights. It will thus be pos- 
sible to reuse large portions of the previous flight plan, resulting in 
lower manpower requirements for planning. For example, procedures 
for operating the equipment will change only slightly and much of the 
Flight Data File can be used again. Also, sustaining activity will be 
appreciably lower than for the first flight of the payload because the 
equipment-procurement cycle will be greatly reduced in scope and time. 
Based on the above, estimates for man-months to plan repeat flights are 
significantly lower than for the first flight of a payload, as shown in 
Table 2-2. 


Table 2-2. Flight Planning Man-Month 

Requirements by Flight Type 



MANFOWER 

REQUIRED ^MAN 

MONTHS 

MYLOAD OtSC tPLINE 

FKSI FlICHT 

RE-FUCHT 

30-DAY FI IGMT 

AmPS 

t09 

62 

123 

ATL 

I2l 

56 

139 

LIFf SCICNCES 

65 

18 

70 

MUITI-AWMCAIIONS 

63 

36 

95 

COMIINED ASTKONOMY 

8F 

40 

100 

FMST MISSION 

n 

- 

• 

MAX)* DIFFERENCE IN 
FUNNINO ACIlVIIY 


• EXFERIMENT 

frocedures 

• FLIGHT DATA 
FILE 

• SUSTAINING 

activity 

• ATTITUDE AND 
POINTING 

• consumahes 


For 30 -day flights, 
attitude and pointing must be 
planned for larger number 
of targets, and consum- 
ables planning becomes 
more complicated because 
the Spacelab' s limited re- 
sources must be stretched 
out over a longer period. 


2. 1. 3 Maximize Use of Existing Computer Resources 

Payload flight planning involves use of computers for many analyses, 
such as determination of pointing angles, consumables profiles and crew 
timelines. Within NASA, a great amount of computer hardware and soft- 
ware is available and can be used for Spacelab payload flight planning. 

This capability is enhanced by the fact that preflight planning is not time- 
critical, making it possible to use institutional resources in a batch- 
processing mode if interactive capability is not available. 

The analysis has considered the capabilities of payload Lead Centers 
to support the anticipated flight rates, leading to recommendation that 
existing computer resources be used for payload flight planning. 
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Estimates for the computational workload for payload flight plan- 
ning have been developed as part of the analysis. The level of flight 
planning is consistent with the other manpower reduction factors. Univac 
1108's have been used for estimating computer hours because this com- 
puter is widely used by candiate Lead Centers, A typical computational 
workload preflight is shown in Figure 2-3. 

Multi-Applications pay- 
loads are "average" for the 
Spacelab payloads, and the 
computational workload for 
this payload is shown. The 
computational hours /month 
are for the first flight of 
Multi-Application payloads. 

An overall analysis has been prepared for computer-supported re- 
quirements including consideration of reflights, and capabilities for the 
candidate Lead Centers. As shown in Table 2-3, only ARC and LaRC 
need additional software capability to do flight planning for their payloads. 
From information gathered during this study and during the STS Payload 
Mission Control Study, it is apparent that a great deal of applicable soft- 
ware is available. 

For the heaviest indicated computer- workloads, at MSFC and 
GSFC, the indicated requirements are only about one hour per day. Both 
MSFC and GSFC operate extensive institutional computer complexes and 
are judged capable of assimilating the indicated workload. 

In summary, computer hardware and software exist within NASA 
to support 10-12 Spacelab flights per year, assuming software support to 
ARC and LaRC by other Centers, 

2.1.4 Use Payload and Mission Specialists in Flight Planning 

Payload and mission specialists will be intimately involved with 
Pi's and equipment designers. They will also participate in testing 
experiment equipment. Their participation in payload flight planning 



Figure 2-3. Typical Computational 
Workload 
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Table 2-3. Flight Planning Capabilities of 
Potential Lead Centers 

• TM-3 10-12 FLIGHT/YEAR • INSTITUTIONAL CAPAtlLITIES 



CAFAUIITIES 

RIQUIREMB4TS 

ASSBSMBIT 

FACILITY 

HARDWARE 

- 

SOFTWARE 

FAYIOAD 

DISCIFLMES 

FRORAM.E 

MAXIMUM 

FITVYEAR 

COMFUTB 
WORK LOAD 
HOURS/YEAR 


ARC 

IBM 360 (2) 
CDC7600 

INCOMPLETE 

LIFE SCIENCE 
ASTRONOMY 

2 

120 

WORK LOAD LIGHT 

POSSIBU CONVERSION 

ORUSEOFNASA 

RESOURCES 

MSFC 

UN IV AC 

nocso) 

ADEQUATE 

SPACE PROCESSING 
AMPS 

MULTI-USER 

MULTI^PPL 

4 

. 

340 

CAPABILITY EXISTS 

WORK LOAD NOT 
EXCESSIVE 

GSFC 

IBM 360(3) 

probably 

ADEQUATE 

SOLAR PHYSICS 
HI-ENERGY PHYSICS 
ASTRONOMY 
MULTI-APPL 

4 

350 

LIMITED 

SCHEDULING S/W 

WORK LOAD NOT 
EXCESSIVE 

LARC 

COC 6000 (5) 

MANNED 

PROGRAMS 

MARGINAL 

ATL 

1 

95 

SOFTWARE UPDATES 
REQUIRED 

WORK LOAD LIGHT ' 

JSC 

UNIVAC 
noo'i (5) 

ADEQUATE 

LIFE SCIENCE 
MULTI-APPL 

2 

120 

WORK LOAD LIGHT 
CAPABILITY EXISTS 


therefore offers definite advantages. In addition to reducing the Lead 
Center's manpower requirements, the use of Payluad and Mission 
Specialists for flight planning improves their understanding of mission 
objectives. Most important, the preparation of experiment timelines 
and procedures by the people who will implement them on-orbit enhances 
the chances for a successful flight. 

A typical crew training schedule is shown in the top section of 
Figure 2-4 and the flight planning activities for the payload are shown in 
the lower section of the figure. A comparison of the schedules and the 
activities being performed indicates that it is both possible and desirable 
to use payload and mission specialists to perform significant portions of 
the payload flight plan. For example, Block B (procedural training on 
experiments) and Block 5 (experiment procedures) occur in parallel and 
should really be performed together, i. e. , experiment procedures must 
be written in order to do the procedural training, and their use in train- 
ing will show what changes are needed to make them realistic. Also, 
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TRAINING SEQUENCE 

(a) screening, orientation and 

^ SYSTEM FAMILIARIZATION 
(?) PROCEDURAL TRAINING ON EXPERIMENTS 
© EXPaiMENT/SPACELAB INTERFACE TRAINING 
(d) combined EXPERIMENTS TRAINING 
0 HABITABILITY AND SAFETY TRAINING 
0 INTEGRATED OPERATIONS TRAINING 
© STS/^PACELAB SYSTEMS O&M TRAINING 

PUNNING SEQUENCE 
0 ORBIT SELECTION 
0 EXPERIMENT TIMELINES 
0 ATTITUDE AND POINTING 
0 CONSUMABLES 
0 EXPERIMENT PROCEDURES 
0 FLIGHT DATAFILE 


MONTHS BEFORE UUNCH 

12 10 8 6 4 ? L 



Figure 2-4. The Payload Flight Crew Can 
Participate in Flight Planning 


orbit selection, experiment timelines, attitude and pointing, and con- 
sumables analyses can impact the procedures for operating the experi- 
ments and should be considered during procedural training on experiments 
accordingly. Blocks 1, 2, 3, 4 are deemed logical activities for the pay- 
load and mission specialists during their training on experiment proce- 
dures. 

Analysis of the training load for the payload and mission specialists 
indicates that time will be available for payload flight planning up to 4 
months prior to launch. The likelihood that backup crew members will 
be assigned and trained increases the amount of specialist's time that 
can be applied to the flight planning activity. Accordingly, it is recom- 
mended that the specialists be used to help develop the payload flight 
plan during their training on experiment procedures at the host center, 
the experiment contractor's facility, or at the Principal Investigator's 
laboratory. 
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2. 1. 5 Summary and Recommendations 

The four manpower reduction factors, the rationale for their 
selection and the advantages are summarized in Table 2-4. Based on 
the analysis performed during the CRAS study it is recommended that 
NASA adopt decentralized flight planning at each payload lead center and 
consider the combination of some aspects of flight planning and flight 
crew training. 


Table 2-4. Evaluation of Manpower 
Reduction Factors 


COST/MANPO/VER 
REDUCTION FACTORS 

RATIONALE 

ADVANTAGES 

MINIMIZE CONTINGENCY/ 
MALFUNCTION PLANNING 

• MOST CONTINGENCIES SOLVED 
BY CHANGES TO TIMELINE 

• SCIENCE/EQUIPMENT MUST BE 
EVALUATED IN REAL TIME 

• REDLICES total MANPOWER 

minimize flight PLANNING 
ITERATIONS 

• DEVELOP FLIGHT PLANS ONLY 
when required TO SUPPORT 
PAYLOAD OPERATIONS 
PLANNING OR DESIGN 

• REPLAN ONLY when HARD 
TEST DATA BECOME 
AVAILABLE 

• REDUCES TOTAL MANPOWER 

• ALLOWS USE OF PLANNERS FOR 
OTHER SYSTEMS ANALYSIS 
ACTIVITIES DURING HARDWARE 
DEVELOPMENT 

• REDUCES COMPUTER USAGE 

MAXIMIZE USE OF EXISTING 
NASA COMPUTER RESOURCES 

• COMPUTATIONAL WORKLOAD 
AT POTENTIAL LEAD CENTERS 
IS WITHIN capability for 10 
flights, 'YEAR model 

• SOFTWARE FOR PAYLOAD 
FLIGHT PLANNING GENER- 
ALLY Exists with nasa 

• REDUCE NEW HARDWARE 
EXPENDITLIRES 

• REDlXE software CON- 
VERSION DEVELOPMENT 

• AVOID LEARNING COSTS OF 
NEW SYSTEMS 

maximize COMMON USE 
OF MANPOWER 

• CREW TRAINING AND FLIGHT 
PLANNING ARE CLOSELY 
RELATED 

• PAYLOAD FLIGHT CREW CAN 
PARTICIPATE IN FLIGHT 
PLANNING 

• TRAINING AND PLANNING 
SEQUENCES ARE SYNCHRONIZED 

• REDUCES lead CENTER MAN- 
POWER REQUIREMENTS 

• MAXIMIZES USE OF highly 

qualified people 

• ENHANCES CONTINUITY FROM 
FLIGHT PLANNING THROUGH 
OPERATIONS 


2. 2 SPACELAB PAYLOAD OPERATIONS CENTER REQUIREMENTS 

The objective of this study was to estimate the equipment, facilities 
and manpower required for a minimum Payload Operations Center (POC). 
The estimates were to be developed for each of the reference payload 
disciplines and for each of the traffic models. In order to accomplish 
these objectives the following tasks were accomplisl ed: 

1) Requirements Definition 

2) Equipment Estimates 

3) Requirements by Traffic Model 

4) Manpower Estimates. 
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2. 2. 1 Requirements Definition 

An analysis was made of eight discipline payloads and of the first 
and second Spacelab missions, as they are defined in the DRM's and Level 
A and B sheets that were issued in the spring and summer of 1975. This 
analysis established the requirements that each payload would have for 
each of the planning functions defined below: 

• Maneuvering 

• Pointing 

• Time Dependencies 

• Orbital Position Relationships 

• Restrictions on Orbiter Operations 

• Special Communications 

• Order of Experirnent Performance. 

2. 2. 1. I Console Requirements 

Based on the planning requirements established, a number of in- 
formation displays and communication situations were postulated. These 
flight planning aids were developed so that a necessary and complete set 
of aids could be defined for each discipline. 

The information displays are broken down into: 

• Those that are of a dynamic nature and so would require 
computer assistance in their formulation either for format- 
ting of data or computation of data products 

• Those that become fixed when the actual orbit has been 
achieved, such as ground track, or those that are supplied 
by external agencies, such as weather prediction. 

In order to develop equipment requirements for the Payload 
Operations Control Center (POCC), as they relate to the amount of plan- 
ning and operational autonomy allowed to the crew, three levels of 
autonomy were defined, 

1) Assistance Only . Full autonomy is allowed the crew except 
that the POCC must be ready to assist in diagnosis of mal- 
functions and in recommending remedial measures either 
through repair or through changes in procedures and plans. 
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2) Minimum Command. This level provides the minimum 
amount of equipment necessary for the POC to command 
instruments when the crew is not available. It also allows 
the POCC to develop daily activity plans for recommenda- 
tion to the crew. 

3) Full Control. This level provides adequate equipment for 

the to do all the planning and instrument commanding. 

It does not provide for a console dedicated to each instru- 
ment in those cases where all instruments will not be 
operated simultaneously. 

Discussions were held with key personnel in NASA Headquarters 
experiment sponsoring offices and with knowledgeable Field Center per- 
sonnel regarding the attitudes of current Principal Investigators toward 
autonomy to the flight crews. The results of these discussions were re- 
inforced by examination of the planned experiment designs as evidenced 
in the Level A and B sheets. 

It is recognized that individual investigator*? may differ from 
these community attitudes. Additionally, there is reason to believe that 
community attitudes will change as experience is gained in Spacelab 
operations. However, the present P. T. communities do have dominant 
attitudes and they differ from discipline to discipline. 

The information and communication requirements, the crew auton- 
omy alternatives and the attitude of Principal Investigators were com- 
bined to develop the most probable combinations of displays, command 
and communication positions required for each reference discipline. 

These most likely configurations are shown, by cross hatch, in Table 2-5* 

Table 2-5. Most Likely Console Configurations 
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2. 2. 1. 2 Data Handling Requirement! 

In order to determine the data handling requirements of the POC, 
the instrument complements of the reference missions were examined. 

The projected data rates for both experiment housekeeping data and 
scientific data are summarized below. 

1) The nominal maximum data rate that can be transferred 
through NASCOM in circuits is 1. 344 megabits per second. 
Presently this rate applies to data transmission from the 
STADAN network or from the TDRSS terminal. Although 
there are discussions about ways to increase this transmis- 
sion from the TDRSS terminal through a Domestic satellite 
link directly to JSC. 

2) All payloads that were studied have total science and house- 
keeping data rates well below 1.344 mbps with the exception 
of AMPS (2. 7 mbps) and Solar Physics (1. 32 mbps). 

3) Although there are a number of instruments that generate 
data at very high rates, there is no practical way to present 
these data in realtime so that their totality can be considered 
by the investigators. Moreover, examination of the instru- 
ments and the type of data to be prodixced indicates that none 
of the projected investigations are concerned with statistical 
aspects of the high rate data. 

4) In order to present high rate data to the investigators in the 
POCC, it will be necessary to either bring the data stream 
to the POC for appropriate sampling or perform this action 
onboard the spacecraft. Onboard sampling can reduce the 
rate so that it can be easily handled by existing communica- 
tion equipment. In contrast, data rates in the range of tens 
of megabits per second have been discussed. Several ele- 
ments of the communications network will require technolog- 
ical development work to assure accurate operation at these 
rates. 

2. 2. 2 Equipment Estimates 

In order to minimize the hardware (and software) in a POC it is 
necessary to limit the functions that it will perform. If an attempt is 
made to satisfy all stated and implied requirements a very sophisticated 
system would evolve. 

The basic job of the POC is to present sufficient data to payload 
personnel so that they can assist in optimizing the scientific observations. 
Except for the commanding of instruments, little can be done by the POC 
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in real time. Most of the deciaione in the POC will have a time scale on 
the order of hours as contrasted to the short time scale of safety related 
decisions. This aspect, in relieving much POC equipment from the neces> 
sity of having to operate in real time, effects a considerable simplification 
in the computational and display components. In order to accomplish 
these tasks the following functional equipments are required. 

s Front End Processor 

Function: Bit sync, decommutate, position and time 

correlate data route to storage 

Capability: Pre-Domsat, up to NASCOM line data rate (1. 34 
mbps); with -Domsat, as required by science (2 to 
3 mbps). 

e Data Storage 

Function: Hold data for access by POC computer system 

Capability; Tape major portions of data stream; quick access 
(disk) storage of working data (1 to 2 M bytes). 

s Computer System 

Function: Access data from POC storage and from MCC, 

develop displays, simple scientific calculations, 
generate command loads, interrupt /prioritize. 

Capability: Not real time, Fortran compatible, access from 

three sources, interrogated by up to 10 peripherals, 

s Consoles 

Function: Request and display data, transfer commands 

Capability; No software, alpha/numeric-display/entry, 

graphics, symbol generator, display refreshment, 
partial display update. 

It is assumed that: (a) payload PCM data will be routed to the POC 
by the MCC directly as received, (b) any payload data that is interleaved 
with Or biter instrumentation data will be stored in the MCC data base and 
is accessible by the POC computer, and (c) the POC can directly access 
Orbiter and Spacelab systems data and trajectory information in MCC 
format. Based on these assumptions and the equipment requirements a 
generalized POC schematic was developed as shown in Figure 2-5. 
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Figure 2-5, Generalized POC Schematic 


The POC will provide for historical storage of all payload data; for 
formatting and display of these data as requested by investigators; for 
formatting of commands to the payload; for voice communication with the 
Spacelab; and for display of Spacelab T, V. 

The POCC consoles will be selected to interface with the POC 
computer and display generator. It would be advantageous if they had 
similar characteristics to those in the MCC so that all consoles could 
access Orbiter data. If this is not practical a special MCC type console 
will have to be provided. The number of consoles and other peripherals 
to be used can be adjusted, over a reasonable range, as demanded by the 
particular flight. 

Table 2-6 below presents types of commercially available equipment 
that can fulfill the required functions. In some instances specific equip- 
ment is mentioned. In others a price is stated which covers a range of 
equipments that are considered adequate to do the job. 

The equipment selection was done by TRW personnel who are actively 
engaged in the design of data handling systems. However, the study was 
performed only to the depth that would develop a general understanding of 
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the equipment needed to perform the functions. Actual design of a POC 
and sizing of the components will require an in-depth analysis of the nature 
of the data and its flow rates. 


Table 2-6, Representative POC Equipment 


FUNCTION 

EQUIPMENT 

ESTIMATED 
COST (1000) 

NUMBER 

REQUIRED 

SYSTEM 
COST (1000) 


COMM. PROCESSOR 

20 

1 


FKONT END FHOCESSO* 
t M»S 

DATA MANAGER 
100 MBYTE DISK 

70 

30 

1 

2 

210 


TAPE RECORDER 

30 

2 



HOCESSOR 



■■■■ 

FRONT END PROCESSOR 

DATA MANAGER 

70 



3 MBPS 

LARGE DISKS 
DISK CONTROLLER 


B 



TAPE RECORDER 

30 




POP 11/70 

70 


■■■jB 

CENGlAl PROCESSOR 

ECLIPSE 300 


n[im 


OISPIAY GENERATOR 

POP 11/70 
ECLIPSE 200 

70 

1 

70 

CONSOLE 

RAMTEC GXlOO DISPLAY 
COMMUNICATION 

25 

X 

X 

ANCILLARY EQUIPMENT 

HARO COPY 

10 

1 

20 


STRIP CHART RECORDER 

10 

1 


SUPPORT EQUIPMENT 

TAPE READS 
CARD READER 


1 

30 


2.2.3 Equipment Estimates by Traffic Model 

A question that should always be examined is whether it is more 
advantageous to provide a large centralized data handling facility or a 
group of smaller facilities keyed to the demand. 

The front end processor and data base operate for only about twelve 
months per year at the 29 per year rate (Traffic Model TM-1). Therefore, 
one set of equipment should, nominally, be able to handle the traffic. How- 
ever, unless adequate ground handling facilities are provided to accom- 
modate to variable launch timing, the occurrence of simultaneous flights 
is about 3 months of the year. Thus, two sets are required at higher 
flight rates. As there are more than two POCC's needed at these rates, 
it would be more economical to have this equipment centralized to service 
all PCX:C's. 

The computer system could also be centralized or distributed. 
However, these elements together with the peripherals are used for POCC 
personnel training. Additionally, the major software changes from flight 


19 































tn flight will be in thie computational eyitem. In a firit order eatimate, 
one could aatume that the total coat for computational equipment will be 
about the aame whether it ia centralized or diatributed. However, the 
centralized computer ayatem muat be aized, at the outlet, for the maxi- 
mum expected traffic. Becauae the ultimate traffic to be accommodated 
ia not known at tiliia time, and becauae a centralized ayatem imposea h^h 
early coata, it ia concluded that the computera ahould be dedicated to 
POCC'a. Additional onea can be purchaaed aa the tragic rate dictatea. 

Software ia conatructed on lead center inatitutional computera uaing 
programs that emulate the POC computer. For mature operations, when 
the emulation programs have been proven, it is estimated that installation 
and test of the software in the POC will take about one month. This time 
wiU vary with the complexity of the flight. In all cases however, the pay- 
load software will change from flight to flight and must be tested in the 
POC environment. It is further estimated that about two weeks should be 
allocated to training of the POC team and ivt integrated simulations with 
the STS flight control team. Equipment and software used in this training 
should be identical to those to be used during flight. It can be demon- 
strated that use of facilities separate from the POC for software testing 
and POC team training will not effect a significant overall saving in 
equipment. 

Overall, the POC will be in use for 50 to 60 days for each t .ven 
day flight and for 75 to 85 days during a 30 day flight. T'lis analysis 
assumes use of the POC's for software and training functions and 
hence a 60-day turnaround for POC's (7 day flights). Each of the traffic 
models have specific numbers of 7-day and 30-day flights. This dictates 
that per facilities are needed for a specific number of months, depending 
on the i'^ngth of time that a POC is used. These data are shown for each 
traffic model in Figure 2-6. 

Figure 2-6 shows that the maximum rate traffic model (TM-1), in 
1991 requires 64 months of POC occupancy. This would call for one more 
POC than the 5 listed. Because no attempt has been made to determine 
the relationship between turnaround time and flight discipline, this is con- 
sidered wiUiin the precision of the study. 
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The total number of each 
type of POC equipment was esti- 
mated by year as a function of 
the traffic models. This is 
based on die previously deter- 
mined numbers of POC's neerted 
and partially on the equipment 
requirements of the most likely 
POCC's and is shown in Table 
2-7. 

In analyzing the most 
likely POCC's, it can be seen 
that only one discipline (Life 
Sciences) would use the mini- 
mum sized POCC. Because of 
this, all POCC's were consid- 
ered to be either Minimum Com- 
mand size or Full Control size. 
The latter was used for all 
astronomy, hi-energy physics, 
and solar physics payloads. Because there is a difference in the number 
of consoles needed between disciplines for either size of POCC, the num- 
ber used was 7 for Minimum Command and 9 for Full Control. This should 
be conservative enough to provide sufficient peripheral equipment so that 
POCC's can be tailored to the specific requirements of each flight. 

Table 2-8 shows the total cost for POC equipment for the three 
traffic models through 1991* This chart demonstrates the sensitivity of 
total costs to the cost of the Front End Processor. Three instances are 
shown: 

1) With the JSC MCC providing front end processing and data 
storage for the POC, no attempt was made to estimate the 
cost of augmenting the MCC to provide this service. 

2) With a »'! megabit per second front end in the P<X^. 

3) With a 2 to 3 megabit per second front end in the POC. 



MOAVniONti 17 7 t 4 ** 

Figure 2-6. Spacelab Ground 
Facility Requirements 
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Table 2-7, Total POC Equipment Requirements 


• MJEO ON 60 DAY POCC TU»N AKOUNO AND MOST LIKELY POCCS 



O REDONOANT SETS - ALSO INCLUDES SOFTWARE INSTALLATION AND TEST EQUIPMENT 
® HARD COPY DEVICE, STRIP CHART RECORDER 
@ ASSUMING SIMILAR CONSOLES TO THOSE IN THE FCR'S 


Table 2-8. Total PCC Equipment 
Costs - Thru 1991 (Dollars in 
Millions ) 


No attempt was made to 
develop cos*-s for a front end 


TRAFFIC MAX. 
MODEL NOS . 

MCC PROVIDED 
FRONT END 
AND DATA BASE 

POC PROVIDE 0 
- 1 MBPS 
FRONT END 

POC PROVIDED 
' 3 MBPS 
FRONT END 

TM - 1 (29) 

).e 

2.7 

5.1 

TM - 2 (16) 

!.? 

2.0 

4.4 

TML -3 00) 

o.« 

1.2 

2.4 


processor Uiat would operate 
at higher data ra'3s because it 
is believed that this will re- 
quire new technology develop- 
ment. 

2. 2. 4 Manpower Estimates 


The manpower estimates 

developed in this study are based on an assessment of the manpower re- 
quired to develop POC software and the number of people required to be 
assigned to the POC for payload operations. 


2.2.4. 1 POC Software Development, Test and 
Integration Manpower Estimates 

Manpower estimates to develop, test and integrate software to 
Support experiment operations in the POC are oased on experience and a 
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understanding of the functions to be performed. The software require* 
ments will vary from discipline to discipline and a much more detailed 
study would be required to make a more accurate estimate. Program 
word size estimates were made based on similar existing programs; these 
were then converted to instructions by an average of 30 words per instruc- 
tion. Manmonths were then estimated using approximatley $31 /instruction 
and $50, 000 per man year as the conversion factors. The estimates for 
system specification and integration were based on the proportion of these 
efforts to total manpower from past software programs. For program 
conversion a "rule of thumb" of 1/4 the manpower of new code was used. 
These data are summarized in Table Z-9. 


Table 2-9. POC Software Development, Test and 
Integration Manpower Estimates 


SOFTWARE PROGRAM 

SIZE 



1 

1 

£ 



SYSTEM SPECIFICATION 

- 


9 

- 

OPERATING SYSTEM 

- 


18 

- 

DATA STORAGE AND RETRIEVAL 

lOOK 

3.3K 

24 

- 

DISPLAY GENERATOR 

100K 

3.3K 

24 

3 

• 40 FORMATS 





DATA BASE STRUCTURING 


- 

18 

y 

MATH MODEL CONVERSION 

(ZOOK) 




• AVG e EXPERIMENT SYSTEMS 

SOK 

1.7K 

12 

i2 

SPECIAL PLANNING PROGRAMS 
CONVERSION 

- 

• 

6 

6 

INTEGRATION AND TEST 

- 

- 

42 

12 

TOTAL SOFTWARE DEVELOPMENT 



153 

42 


2. 2, 4. 2 POC Manning, for Training and Operations 

In order to develop estimates of manpower requirements for the POC 
a baseline scenario was generated. It is estimated that about three weeks 
would be required for indoctrination and training so that the POCC team 
would be capable of operating effectively with the STS Operator and Crew 
in integrated simulations. This means that about 3-1/2 weeks would be 
required preflight, as shown in Figure 2-7. 
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1 
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SCHEOUie 

WEEKS -4 -3 -2 -1 LAUNCH 1 2 

I I I I I I I 

I ~~1 INDOCTRINATION 


1 7JT~ 

TRAINING AND SIMIAATIONS 


FLIGHT SUPPORT 


I ~1 POST FLIGHT 

I 1 ACTIVITIES 

Figure 2-7. Baseline POC Manning Scenario 

At least a half-week post flight should be provided for POC partici- 
pants to investigate the nature of the recorded data and to establish with 
the MCC the type of Orbiter and Spacelab data needed for the scientific 
analyses. Thus, the participants are expected to be in residence 5 weeks 
for a 7 -day flight and 8 weeks for a 30-day flight. 

The payload manager should be in residence and have primary 
responsibility for payload operations. Based on Apollo and Skylab experi- 
ence, there should be a chief scientist who has responsibility for making 
decisions between investigators where there are conflicting demands on 
flight resources. He should be available for each days' activities plan- 
ning and for preplanning strategy sessions. This could take as much as 
16 hours each day. There should be a payload flight planner in charge of 
each shift. Experiment development engineers and investigators should 
be operating in the POC on all shifts. The number of these depends on 
the number required by the payload. For this analysis the numbers are 
matched to the number of consoles provided in the most likely POCC's. 

Total numbers of personnel in-residence are shown in Table 2- 10 as 
a function of the POCC autonomy alternative. The equipment support 

personnel are required only for 
payload unique equipment. The 
operations and maintenance of 
other POC equipment can be best 
supplied by MCC personnel. 

Using the previous scenario 
it is estimated that POCC man- 
ning should be about 28 for a 
Minimum Control POCC and 35 


Table 2-10. POC Manning, Training 
and Operations 



AO • ASSISTANCE only 
MC • MlNiMUW COMMAND 
FC • FLAl CONTftOL 
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for a Full Control POCC. They should be in residence for about 5 weeks 
for a 7 -day flight and about 8 weeks for a 30 -day flight. 

With the most likely POC's proscribed, the manpower requirement 
averaged across each traffic model is about 40 manmonths per flight. 

2. 2. 4, 3 Lead Center POC Manpower Estimates 

Based on the previously presented data, an estimate of the total 
equivalent manpower needs of each of the potential lead centers was made. 
This is shown in Table 2-11 in man years by lead center and traffic model. 


Table 2-11. Manpower Estimates by Discipline 
and Traffic Model 


OPtRATIONS 

• MANNING 28-35 

• DURATION 5-8 WEEKS 

• AVERAGE 40 MAN MONTHS 


SOFTWARE 

• 153 MAN MONTHS FIRST FLIGHT 

• 42 MAN MONTHS REFLIGHT 


TRAFFIC MODEL 

MANPOWER ESTIMATES IN MAN YEARS | 

MSFC 

GSFC 

LoRC 

JSC 

ARC 1 

S/D 

OPS 

S/D 

OPS 

S/D 

OPS 

S/D 

OPS 

S/D 

OPS 

TM-1 (29) 

290 

265 

185 

165 

132 

120 

73 

60 

69 

55 

TM-2 (16) 

163 

145 

128 

no 

65 

55 

55 

45 

51 

40 

TM-3 (10) 

10/ 

90 

100 

85 

41 

30 

EB 

30 

34 

20 


S/D - POC SOFTWARE DEVELOPMENT, INTEGRATION AND TEST 
OPS - POC OPERATIONS 


2. 2, 5 Summary and Recommendations 

The equipment, manpower and facilities required for a minimum 
POC were evaluated and assessed. The following points summarize the 
study results: 

1) A modular POC, based on the use of mini/micro processors, 
can support payload operation for an estimated cost from 
400 thousand to 2 million dollars each. 

2) The cost of the POC varies mainly because of alternatives 
in the processing of science data: 

Science Data Rate POC Cost 


<128 kbps 

< 1 mbps 

< 3 mbps 
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=s$ 400K each 
«$ 800K each 
^$2000K each 
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3) Manpower estimates for POC software development and 
operations average 80 to 100 man months per flight; POC 
software (40 to 60) and POC operation (40). 

4) As many as five POC facilities are required to provide 
reconfiguration, training and real time support. 

Based on these results it is recommended that the NASA plan for a 
modular POC based on the use of mini/micro processors and review the 
real need for high rate science data in the POC. Additionally, means to 
reduce the manpower requirements should be studied such as standardized 
software units and the use of firmware in place of software. 

2. 3 EXPERIMENT DATA PREPROCESSING ALTERNATIVES 

The objective of this study was to analyze the alternative approaches 
to experiment data preprocessing. Alternatives were developed based on 
the requirements of each payload, the communication links available and 
equipment and software required for ground preprocessing. 

There are two objectives of the data preprocessing function; to 
provide high quality data tapes which can be reduced and analyzed by the 
user, and to provide a limited amount of data for real time or near real 
time data display. The activities required to prepare the data for analysis 
and interpretation are performed and paid for by the user and are not a 
part of this study. 

The functions described below are those activities which are required 
to provide the user with high quality, comjiuter compatible digital tapes 
ready for processing and analysis. The data is to be calibrated and grouped 
in blocks of science data by experiment. 

• Create time continuous, non-redundant computer 
compatible data files 

• Telemetry data reduction 

• Perform data quality control and flag questionable data 

Verify frame sync 

Time correction/correlation 

Event status 

Reference voltage verification 
Transmission error detection 
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• Group data into functional blocks 

- Calibration 

- Science data by experiment 

• Provide selected data for quick look display. 

2. 3. 1 Requirements 

Several questions need to be discussed with respect to 50 mbps 
real time data. That much data is clearly much more than could be eval- 
uated during the flight. If this is true, then where does the requirement 
come from? Our review of the data generated by the DRM experiments 
and other missions indicates that there are several imaging type sensors 
which generate 50 mbps or more. The DRM's indicate that these data will 
be stored onboard. The real time experiment data rate requirements 
established by the DRM's are shown in Figure 2-8. 



Figure 2-8, Real Time Experiment Data Requirements 


However, for the purpose of this study it has been assumed that the 
50 mbps real time data is required. There are several advantages of real 
time data transmission. The data is available on the g >und for real time 
decision making and there is no need to record onboard in expensive flight 
qualified recorders. There are disadvantages, too. A re work of satellites 
and land lines is required to send the data to the processing site. This 
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could include TDRSS, DOMSAT, receiving stations for each system, and 
microwave links between centers. Additionally, to process the data in 
real time some technology advancement would be required. 

2. 3. 2 Data Communications Link Alternatives 

The communication links available to Spacelab payloads in the 
operational era have not been defined. There is the possibility of the use 
of the Tracking and Data Relay Satellite (TDRS) and the Domestic Satellite 
(DOMSAT) systems for relaying data to the ground for preprocessing. An 
overview of these possible alternatives is shown in Figure 2-9. 



I ) maximum bit rate 

Figure 2-9. Data Communications Link Alternatives 


As shown in the figure, the following alternatives are available 
within the planned NASCOM system, to transmit and distribute the experi- 
ment data from Spacelab. 

• Orbiter operational instrumentation link~<2 mbps 

• Record onboard Orbiter - bringdown or playback ~400 to 
500 mbps 

• T/M via TDRS - record and ship tapes -50 mbps 

• T/M via TDRSS - record then playback through landlines 
~sl. 344 mbps 

• T/M via TDRSS/DOMSAT directly to center(s) ,.^<50 mbps. 
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The advantages and disadvantages of each of these options is sum 
marized below. 


COMMUNICATIONS 

LINKS 

ADVANTAGES 

DISADVANTAGES 

• ORBITEK 01 LINK 

• LOW COST 

• EQUIPMENT AVAILABLE 
AT MCC AND ONBOARD 

• REAL TIME DATA 

• SPECIAL DATA HANDLING AT EXPERIMENT 

• LIMITED TO 2 MBPS 

• RECORD 
ON-BOARO 

• NO COST TO S/L 

• NO REAL TIME DATA 

• V2EIGHT IN ORBIT 

• FLIGHT QUALIFIED RECORDERS 

• NO QUICK LOOK DATA 

• LIMITED AMOUNT OF DATA 

• FSEOUENT CHANGING OF TAPES 

• RECORD AI TDRSS 
GROUND 
STATION 

• ONLY GROUND RECORDER 

needed 

• NO ONBOARD IMPACT 

• NO REAL TIME DATA 

• NO QUICK LOOK DATA 

• PLAY BACK THRU 
LAND LINES 

• QUICK LOOK DATA 

• JSC, GODDARD LAND 
LINES EXIST 

• COST OF ADDITIONAL LAND LINES 

• LIMITED TO 1,344 mbps 

• COMPLICATES GROUND STATION OPERATION 

• DOM SAT RELAY 

• REAL TIME DATA 

• MULTIPLE SITE RECEPTION 

• COST OF DOMSAT RECEIVERS 

• DOMSAT RENTAL 


Z. 3. 3 Data Preprocessing and Quick-Look Alternatives 

A concept of the preprocessing system including the front end pro- 
cessor, i. e. , the interface between the telemetry receiver and the pre- 
processing computer and the computer system is shown in Figure 2-10, 



Figure Z-lO. Function Description of the Data 
Preprocessing System 






Experiment digital data that has been put on the high rate data link 
is signal conditioned and phase detected. The data is then bit synchronized 
(or symbol synchronized, if encoded), decoded (if previously encoded), 
and frame synchronized. The frame synchronized digital data is then 
decommutated, serial-to-parallel converted, and interfaced with the pre- 
processing system computer for calibration, editing and quality control, 
regrouping, and the creation of computer compatible data files or tapes. 
Recording of the raw digital data for storage and subsequent playback 
would take place before the data has been converted to a digital bit stream 
by the bit (or symbol) synchronizer. 

High data rate limitations occur in the data synchronization/decoding 
process. Synchronization hardware has been demonstrated at high bit 
rates; however, there is an increase in the bit error rate. In order to 
achieve the high fidelity bit signal required for Spacelab, error correction 
coding is necessary. 


Convolution encoding and 
decoding becomes necessary 
when, with the available RF 
power and antenna systems, it 
becomes impossible to obtain 
a signal-to-noise ratio high 
enough to give an acceptable 
bit error rate. 


U= LINCODED 


< 

a: 

o 

oe, 

oe. 



B = BLOCK ENCODED 

C = CONVOLUTION 
\ y ENCODED 

\b \ 




SIGNAl/NOISE RATIO 


Current technology can provide bit/symbol synchronizers up to 5 
mbps, and are projected to operate at 50 mbps in the Spacelab time 
period. 

Convolution decoders are currently being developed which can work 
at up to 5 mbps, and in the time frame of Spacelab, should be available 
to work in the 10 to 15 mbps range, NASA is expected to conduct studies 
to advance this technology for STS applications in the near future. In 
order to handle higher data rates, the data stream must be split and the 
decoders employed in parallel. Figure 2-11 depicts the 'parallel" con- 
cept being considered to implement the handling of high telemetry data 
rates beyond the capability of anticipated decoding equipment. 
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Figure 2-11, Anticipated Approach to Processing 

Data Rates Greater than 10 to 15 MBPS 


Basically, this process would separate the high-rate digital data 
stream in the Orbiter into a number of lower rate data streams; each of 
these lower rate data streams would be capable of being handled by en- 
coding/decoding equipment. Each of these lower rate data streams would 
be separately encoded in the Orbiter and then multiplexed together for 
transmission to the ground. On the ground, the multiplexed signal would 
be demultiplexed into the component signal streams and each of these 
component signal streams would then be individually bit/ symbol synchro- 
nized, decoded, and then merged back together to form the total high data 
rate bit iJtream, which is then available for frame synchronization and 
subsequent preprocessing steps. 

The pros and cons of the preprocessing alternatives are shown 

below. 


PREPROCESSING 

1 

advantages ' disadvantages 

• REAL TIME AT PAYLOAD 
CENTER 

• data available for 1 • state of the art equipment 

processing and display ^ REQUIRED 

IN NEAR REAL T’“AE 

• AVAILABLE EQUIPMENT N • NOT AVAILABLE IN REAL-TIME 

ADEQUATE 

• STORE AND PLAYBACK 












There appears to be no advantage to real time preprocessing of the 
high rate data. Additionally, the capability to perform real time, high 
data rate preprocessing requires an advancement in the technology for 
front-end processing. The data can be stored and played back at slower 
rates and preprocessed on existing equipment. To provide data for 
scientific evaluation in the payload operations center three alternatives 
appear possible, the advantages and disadvantages of these options are 
Summarized as follows. 


QUICK LOOK 

ADVANTAGES 

DISADVANTAGES 

• REAL Tl^f SNAPSHOT OP 

• DATA AVAILABLE IN 

• REAL TIME DATA ACCESS 

50 MB DATA 

REAL TIME 

• DATA MUST BE IDENTIFIED AND 



SEPARATED FOR DISPLAY 

• STORE AND PLAYBACK OF 

• AVAILABLE EQUIP. 

• DATA MUST BE IDENTIFIED AND 

SO MB DATA 

• DATA AVAILABLE ~ 4 HRS 

SEPARATED FOR D!.'-PLAY 

• USE OF REAL TIME 

• REAL TIME DATA 

• EXPERIMENT LQUKMENT MUST SEND 

INSTRUMENTATION LINK 

• AVAILABLE EQUIP. AT MCC 

DATA TO BOTH K BAND AND 



OPERATIONAL instrumentation 


Quick look information can be inexpensively obtained by placing all 
payload data for real time display on the Orbiter operational instrumenta- 
tion link. 

2. 3. 4 Study Results and Recommendations 

The real time preprocessing of 50 mbps does not appear to be 
required: 

• Maximum DRM real-time data rate only 2. 7 mbps 

• 50 mbps provides too much data to be evaluated in real-time 

• High data rate sensors /missions plan to record their data 

• Ground versus on-board data recording tradeoffs need to 
be considered. 

The preprocessing of experiment data should be accomplished by 
recording the data as it is transmitted and playing the data back at low 
speed to minimize costs. 

• Lower cost data communications 

• Simpler, cheaper telemetry data handling 
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• Less need for special purpose or dedicated preprocessing 
comp .ter hardwaxe 

• Increased ability to use currently available equipment. 

Data that is required to evaluate the performance of the instruments, 
both scientific and housekeeping, should be downlinked on the Orbiter 
instrumentation link (~2 mbps), processed in the MCC and routed to the 
POC for display, 

• Capability will exist at MCC after OFT 

• Current equipment is adequate. 
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3. FLIGHT CREW TRAINING 



The general objective of this task is to define and evaluate logical 
alternative approaches to Spacelab flight crew payload associated train- 
ing whinh, when compared to the SBPP» reduce the investment in sup- 
porting facilities, hardware and software and training personnel, but do 
not compromise safety or system performance. 

Following the mid-term briefing TRW was directed to perform the 
following activities in addition to those defined in the NASA Statement of 
Work for this task. 

1} Update the Spacelab design baseline and examine the 

impact of remote control upon the operations task analysis. 

2) Examine the pros and cons of using the Hi-Fi Mockup, the 
Engineering Model and Concept Verification Test/General 
Purpose Laboratory Simulator (CVT/GPLS) in the training 
of the flight crew and p>ayload and mission specialists. 

3) Examine the possibility of incorporating flight crew and 
payload and mission specialist training into levels II and 
III Shuttle /Spacelab/ Payload integration. 

4) Based upon the results of the revised task analysis and the 
applicability of the following planned for equipments, re- 
examine the need for the $6. OM Spacelab simulator. 

The following material describes the processes employed and prod- 
ucts generated to accomplish the task objectives and special study require- 
ments. 

3. I CREW TRAINING TASK ANALYSIS/REQUIREMENTS DEFINITION 

In order to define cost effective approaches to Spacelab flight crew 
training, it is first necessary to define the training requirements. A 
systems approach was used in performing the analyses necessary to de- 
fine these requirements. This systems approach consisted of the follow- 
ing steps. 

It first entailed an analysis of the Spacelab design in order to define 
the function, operation and performance capabilities of the equipment. 

Next, an analysis was performed to identify the following: 
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• Manned operation* and interactions with the equipment 
e Time and performance criticality of manned operation* 

* Skill* and knowledge le^^el* required to perform the task* 

e Type* of training equipment required to develop requisite 
skills and knowledge. 

Once the manned operations requirement* are defined and docu- 
mented, the training objectives for each manned position are collated 
and a training; program and training sequence developed which ensures 
the systematic find timely development of required skills and knowledge 
in the personnel. 

Task level training equipment requireme tts are assimilated into 
meai.ingful composites and referenced to the appropriate training objec- 
tives which they would effectively support. 

Next, planned or existing equipment which have potential to satisfy 
the training requirements are analyzed and the efficacy oi their use in 
the training program evaluated. 

Recommendations as to the types and numbers of equipment neces- 
sary to support the training of the flight crews are developed based upon 
requirements, available and planned resources, schedule and cost. 

The task analysis . avealed that the same basic taskr are performed 
in operating the Spacelab subsystems in support of all types of payloads 
although, for pallet only modes, operator tasking is redo; > by elimina- 
tion of the module e.: /ironmental control system (ECI^S), 

With the possible exception of the IPS activities, both nominal and 
contingency operation of Spacelab subsystems are procedural (step-by- 
i^tep), follow a logical cause and effect relationship, are of low i.u mod- 
erate complexity and, to a great extent, can be scheduled. 

All tasks identified on the training analysis worksheets were analyzed 
and iiummarized according to on-orbit equipment gr^oup operations, then 
converted into categories of instruction and objectives of instruction 
within each category. Personnel assignments, per NASA job descriptions, 
were made against each training objective. 
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The training equipments identified on the training analysis work- 
sheets were assimilated into composite training devices and grouped 
according to training equipment types - mockup, part task trainer/ 
simulator, actual equipment and special interface equipment. "Actual 
equipment" consists of restraint devices, flight planning kits, pressure 
garments, etc. These data are included in Volume III of this report. 

3. 2 PROS AND CONS OF USING HI-FI MOCKUP, CVT 
AND ENGINEERING MODEL IN TRAINING 


The training application and negative factors of the hi-fi mockup, 
CVT and engineering model are summarized in Table 3-1. 


Table 3-1. Examine Pros and Cons of Using Hi-Fi Mockup, 
CVT and Engineering Model in Training 


TRAINING EQUIPMENT 

TRAINING APPLICATIONS 

NEGATIVE FACTORS 

CONCEPT VERIFICATION 
TEST/GENERAL PURPOSE 

lAB 

• EXFERIMENT/COMS PROFICIENCY 
TRAINING 

• INTEGRATED EXPERIMENT 
OPERATIONS EFFICIENCY 
TRAINING 

• MISSION EXPERIMENT 
SIMULATIONS 

• CANNOT SUPPORT FULL 
TRAFFIC MODEL 

• CANNOT SUPPORT CVT AND 
TRAINING FOR TM-3 

• APPROXIMATELY SAME 
BENEFITS COULD BE GAINED 
BY INTEGRATING PART TASK 
TRAINERS 

ENGINEERING MODEL 

• SPACELAB SUBSYSTEMS 
OPERATIONS AND MAIN- 
TENANCE PROCEDURES 
TRAINING 

• REQUIRES MODIFICATION FOR 
USE AS TRAINER 

• TRAINING MODIFICATION 
DEGRADES USE FOR GROUND 
CREW TRAINING AND 
SUSTAINING ENGINEERING 

HI-FI MOCKUP 

• PROCEDURES TRAINING 

• SPACELAB familiarization 

• UPGRADE TO SPACELAB 
TRAINER 

• availability for MODIFI- 
CATION at JSC 


The design of the CVT/GPLS limits it application in the Spacelab 
training program to Spacelab systems /experiment interface (proficiency) 
training and experiment operations (efficiency) training of payload and 
vnission specialists. This type of device would probably prove to be very 
beneficial for integrated experiment operations, CORE use and integrated 
experiment CDMS/experiment interface/experiment operations interaction 
training. Further, flight data file development, crew activity planning and 
similar functions could be supported with such a device. 

As EM-1 is functionally and dimensionally identical to the flight 
unit, includes the AFD PSS workstation and Orbiter interface adapter, 
all Spacelab O&M procedures can be performea on the EM as they would 


36 















on the flight unit in a 1-G environment, with the exceptions noted above. 

In addition, as the components are identical to the flight hardware fault 
isolation, item remove /repair /replace actions can also be performed 
within the context of the 1 -G environment. 

Modifying the EM to make it an efficient and effective training de- 
vice would be quite costly and may detract from its effective use as an 
inflight maintenance support or sustaining engineering tool. The EM 
coxild in its present form, support habitability, familiarization, safety, 
both primary and refresher subsystem operations and maintenance and, 
to a limited extent, integra.ed flight crew operations training. 

The Hi-Fi mockup is a sophisticated, detailed, full-scale represen- 
tation of the physical elements of the Spacelab module. The physical 
characteristics of the components, subsystems and structures are repre- 
sentative of the flight unit design. The Hi-Fi mockup is planned to be 
used by JSC as the Spacelab 1-G trainer. The trainer is to be used in 
support of flight crew procedures training, hardware development, and 
flight crew training exercises for EVA, safety, stowage and habitability 
operations. 

It is recommended that the mockup be upgraded to full trainer 
status in the subsystems areas. Experiment areas would remain as 
envelope fidelity only. The control and display elements would be elec- 
trically/electronically connected to replicate their system operating 
functions and be controlled through an instructor's console. CDMS dis- 
play formats and control capability may well be capable of being simulated 
through an "intelligent" terminal, microprocessor approach as the func- 
tions it performs are, predominantly procedural in nature. 

3. 3 EVALUATION OF INCORPORATING CREW TRAINING 
INTO LEVELS II AND III INTEGRATION ACTIVITIES 

The Level II integratipn facility consists of flight hardware and a 
series of electrical and support equipment to simulate Orbiter resources, 
supply power, provide operator control and display and test and services. 
The Orbiter interface adapter will simulate the Orbiter; it will include a 
PSS simulator, Spacelab/ Orbiter signal simulator and power distribution. 





The facility may be used for experiment activation through the actual 
Spacelab interfaces and to provide limited experiment operations. Con- 
straints on operation are imposed by the experiment systems such as 
booms, etc. which may not be operated prior to launch. The Level II 
integration facility should be used for refresher training only. In addi- 
tion to the limited experiment hardware operations capability, Level II 
integration will be accomplished over a period of approximately 5 days of 
2-shift operations ending 2 weeks before launch. Under ^hese time con- 
straints the facility cannot be recommended for basic training. 

The Level III integration facility consists of flight experiment hard- 
ware and electrical and support equipment to simulate Spacelab data 
interfaces, data handling and power distribution. The facility may be 
used for experiment activation through flight type interfaces, but not in 
the actual environment. The experiments may be constrained from 
operation at this time. The Level III integration activity is too close to 
launch to be acceptable for primary training. It will be suiteable for 
refresher training on activation/operation procedures. 

3. 4 TRAINING EQUIPMENT RECOMMENDATIONS 

The type of equipment recommended for support of Spacelab sub- 
systems, STS/SL/Payload Interface and Integrated Operations training for 
various flight loads is shown in Figure 3-1. 

AfD-m/S MODOU fTKS) UStllNI SET 



• KAIITAIILITY. SAFny, PtANNINC AND MISSION ‘SIMS' TKAINING 

•COAWINE WITH SMS AND OAHU* l-G 
• nOVIDE TELEMCrilY AND VOICE LINK WITH MCC 


Figure 3-1. Training Equipment Recommendation 
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IZ to 15 Flights /Year 

The baseline equipment set consists of an AFD Part Task Trainer/ 
Simulator and Module PTT(S) with required GSE and Instructor's console 
for primary instruction. The EM and Levels II and III integration facil- 
ities would be used to supplement the primar/ training. 

As previously described, the Spacelab sub ystems manned opera- 
tions tasks in both the AFD and Module require a training device of no 
greater than trainer level complexity, except for IPS operations. Inter- 
connection of the two through an instructor's console would enable their 
independent or integrated use. Because op^'rations and displays are not 
dynamic but discrete, and control/response actions are relatively slow, 
control of components for malfunction ir -ertion or level changes can be 
performed manually through the insirucio: station. 

If the AFD-PTT/S and Module PTT/{S) are incorporated into the 
SMS, MDM inputs to the SL and outputs to the MDM could also be imple- 
mented through the instructor console. This arrangement could effec- 
tively support all JSC Spacelab operations, interface and integrated 
simulations training requirements. However, the lack of experiment 
equipment precludes actual hardware operations experience in this area. 

A comparison of the recommended trainer with the six million 
dollar Spacelab simulator is shown below. 

JSC Simulator 

• Basic interior module • 

and AFD structure 

• AFD C&D (plug-in) • 

• Actual flight computer • 

( 2 ) 

• Full computer driven • 

simulation of all SS and 
CPSE operations and 
phenomena 

• Direct interface to SMS • 

computer and software 


TRW Alternative 
Same (Hi-Fi mockup) 

Similar- intelligent terminal's 
(MDM and RAU) 

Commerical mini or micro 
processor (if required) 

Full functional represen- 
tation of SS and CPSE 
operations 

Isolated from SMS computer 
by instructor's console 


39 


JSC Simulator 


TRW Alternative 




« 


( 


• Preprogrammed malfunc- 
tions 


• Remote manual malfunction 
insertion 


• Dynamic telemetry data • Possible - could use canned 

tapes 

• No visual -SMS supplied • Same 

The functions are basically the same, however, the TRW alterna- 
tive uses the advancing state-of-the-art in mini/micro processors to 
minimize costs. 


20 to 23 Flights/Year 

The addition of another AFD trainer to the baseline equipment set 
would nearly double the Spacelab training capacity. The flight load which 
can be supported by the basic set is dependent upon the types of payloads. 
Pallet only configurations comprise nearly 50 percent of the missions. 

25 to 29 Flights /Year 

The training equipment described above can be made to support 
25 to 29 flights per year with the addition of "D" level Spacelab mockup. 

A low systems fidelity, high envelope fidelity mockup would enable 
off-loading of the Module trainer for basic familiarization, safety, and 
mission "SIMS" walk-through training of Payload Specialists. 

3. 5 SUMMARY AND RECOMMENDATIONS 

The results and recommendations of the crew training tasks are 
summaried in the form of answers to the special questions from the mid- 
term briefing; as follows: 


1) Evaluate impact of remote control on task analysis. 

No significant changes from initial analysis. 

Some modifications as to how and where functions 
are performed. Simplified control and display panels, 

2) Reexamine need for $6M Spacelab simulator. 

Training devices required but full simulation is 
not mandatory. 
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Examine applicability of Hi-Fi mockup, CVT and EM 


to training. 


Hi-Fi Mockup 

- Upgrade to trainer status on 
subsystems, lo-fi mockup of 
experiment C&D 

CVT 

- Can be used for proficiency 
development 

EM 

- Use for refresher training. 


Examine possibility of incorporating Levels II and III 
integration into crew training. 

Use for refresher training with crew as test 
engineers. 
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